PSM I Practice Exam — PSM I : Master™ I

When multiple Scrum Teams collaborate on a single product, a core Scrum requirement is that a single, potentially releasable Increment is produced every Sprint. This requires full integration of all work completed by every Scrum Team contributing to the product each Sprint. Scrum operates on empirical process control, which relies on transparent, accurate inspection of work to enable effective adaptation. If Increments are not fully integrated every Sprint, the Product Owner and stakeholders cannot see the true, functional state of the product, which prevents accurate assessment of delivered value, identification of integration defects, and informed decision-making about product direction, release timing, and Product Backlog prioritization. The suggested answer B directly aligns with this core Scrum requirement, as it ties the mandatory integration of all Increments to the critical need for accurate inspection by the Product Owner and stakeholders. Option Analysis:
A. Incorrect. All Increments from all Scrum Teams working on the same product must be integrated every Sprint, regardless of perceived dependencies. Even if teams believe their work has no cross-team dependencies, unforeseen integration conflicts, performance issues, or functional gaps often emerge only when full integration is performed. Partial integration of only dependent teams' work leads to an incomplete, untested product state that does not meet the requirement for a potentially releasable Increment.
B. Correct. This aligns with the empirical Scrum pillar of Inspection. The Product Owner is accountable for maximizing product value, which requires accurate, real-time visibility into the complete functional state of the product every Sprint. Without full integration of all Increments, the Product Owner and stakeholders cannot reliably assess if the combined work of all teams meets quality standards, delivers intended value, or is suitable for release, leading to flawed adaptation decisions.
C. Incorrect. While individual Scrum Teams are self-managing and cross-functional, teams working on the same shared product are part of a unified product delivery group and do not operate in isolation. Their work contributes to a single shared product Increment, so integration of all team outputs is required to deliver a cohesive, usable product every Sprint.
D. Incorrect. Scrum does not support the use of hardening Sprints, as all work required to deliver a usable, potentially releasable Increment must be completed within every regular Sprint. Hardening Sprints introduce undone work, break the regular cadence of inspection and adaptation, and violate the core Scrum requirement that each Sprint delivers a usable Increment. Integration work is part of the work required to meet the product's Definition of Done, so it must be completed every Sprint, not deferred to a separate hardening Sprint. Key Concepts:
1. Potentially Releasable Increment: A core Scrum artifact, the Increment is a concrete, usable stepping stone toward the Product Goal. For multiple teams working on one product, all team outputs must be integrated into a single Increment that meets the shared Definition of Done every Sprint, so it can be released at the Product Owner's discretion.
2. Empirical Process Control (Inspection Pillar): Scrum is based on empiricism, which asserts that knowledge comes from experience and decisions are made based on what is observed. Regular, accurate inspection of the Increment ensures that teams and stakeholders can identify gaps or defects early, and adapt their plans appropriately. Without full integration of all Increments, inspection of the actual product state is impossible.
3. Scaled Scrum Requirements: When scaling Scrum for multiple teams on a single product, all core Scrum rules still apply. The Nexus Guide, the official Scrum scaling framework for multiple teams on one product, explicitly requires a single integrated Increment across all teams every Sprint to maintain transparency and support valid inspection. References:
Scrum Guide 2020, https://scrumguides.org/scrum-guide.html
Nexus Guide 2024

This question assesses understanding of exclusive role accountabilities within the Scrum framework, specifically related to Sprint cancellation authority. Per official Scrum guidance, Sprint cancellation is a decision reserved exclusively for the Product Owner, who is accountable for maximizing product value and maintaining the Product Backlog. The Development Team does not hold authority to cancel a Sprint, regardless of operational or technical challenges encountered during the Sprint. If the Development Team faces issues that impact their ability to deliver against the Sprint Backlog or Sprint Goal, they are required to collaborate with the Product Owner to renegotiate Sprint Backlog scope, identify workarounds, or escalate concerns about Sprint Goal viability to the Product Owner, who alone can make the decision to cancel the Sprint if the Sprint Goal is no longer relevant. Option Analysis:
A. Correct. The 2020 Scrum Guide explicitly states that only the Product Owner has the authority to cancel a Sprint. The Development Team has no decision-making power to end a Sprint early, so it cannot cancel a Sprint under any circumstance.
B. Incorrect. If functional expectations are unclear, the Development Team is required to collaborate with the Product Owner during the Sprint to clarify requirements, rather than canceling the Sprint. Unclear requirements are a common, solvable challenge within Sprints that does not justify cancellation, and the Development Team has no authority to cancel regardless.
C. Incorrect. Frequent Product Owner absence does not grant the Development Team cancellation authority. The team can prioritize work on Sprint Backlog items that are already well understood, and escalate gaps in Product Owner availability to the Scrum Master or organizational stakeholders if needed, but cancellation remains exclusively the Product Owner's decision.
D. Incorrect. If selected Product Backlog items are unachievable, the Development Team works with the Product Owner to adjust the scope of the Sprint Backlog to align with their capacity, as long as the Sprint Goal remains viable. Even if the Sprint Goal is no longer achievable, only the Product Owner can choose to cancel the Sprint, not the Development Team.
E. Incorrect. Unresolved technical dependencies are addressed by the Development Team through collaboration with relevant stakeholders, identification of alternative implementation paths, or negotiation of scope adjustments with the Product Owner. These challenges do not give the Development Team authority to cancel the Sprint. Key Concepts:
1. Sprint Cancellation Authority: This core Scrum rule specifies that only the Product Owner may cancel a Sprint, as they are the accountable party for determining if the Sprint Goal is no longer valuable to pursue, aligned with their mandate to maximize product value.
2. Development Team Accountabilities: The Development Team is responsible for managing their own work to deliver a potentially releasable Increment each Sprint, but they do not hold authority over decisions that impact the overall value direction of the product, including Sprint cancellation.
3. Sprint Problem Resolution: Routine challenges encountered during a Sprint, including unclear requirements, technical blocks, or capacity gaps, are resolved through internal collaboration between Scrum Team members, not through Sprint cancellation, which is reserved only for cases where the Sprint Goal becomes entirely obsolete. References:
The 2020 Scrum Guide, https://scrumguides.org/scrum-guide.html
Professional Scrum Master I (PSM I) Competency Areas

Per the official Scrum Guide, which is the core reference for the PSM I certification, Sprint Planning is the first event of a Sprint where the Scrum Team collaborates to define what will be accomplished in the upcoming Sprint and how that work will be delivered. The question specifically asks for the output that provides the Development Team with a target and overarching direction for the Sprint. The Sprint Goal is exactly this output: it is a single, cohesive objective agreed to during Sprint Planning that unifies the Development Team, provides a clear shared target, and allows the team flexibility in the exact scope of work needed to achieve the goal, rather than dictating every task upfront. This directly matches the description in the question, making the suggested answer B correct. Option Analysis:
A. The Sprint Backlog. Incorrect. The Sprint Backlog is the other core output of Sprint Planning, consisting of the selected Product Backlog items for the Sprint plus the actionable plan to deliver those items and meet the Sprint Goal. It is a detailed, evolving work plan for the Sprint, not the overarching directional target referenced in the question, so it does not meet the requirement.
B. The Sprint Goal. Correct. As defined in the Scrum Guide, the Sprint Goal is the singular, unifying objective for the Sprint created during Sprint Planning. It provides the Development Team with a clear shared target and overarching direction, and the team adjusts their work throughout the Sprint to stay aligned with this goal, which exactly matches the question's description.
C. The release plan. Incorrect. A release plan is not an official output of Sprint Planning. It is an optional, cross-Sprint planning artifact focused on forecasting when product increments will be released to users, and it does not provide direction for a single Sprint. Since it is not produced during Sprint Planning, it is not a valid answer.
D. Sprint Review minutes. Incorrect. Sprint Review minutes are an unofficial, optional document created after the Sprint Review event, which occurs at the end of a Sprint, not during Sprint Planning. They are unrelated to setting direction for the upcoming Sprint, so this option is entirely incorrect. Key Concepts:
1. Sprint Goal Core Purpose: The Sprint Goal is the directional output of Sprint Planning that provides a shared, unifying objective for the entire Sprint, allowing the Development Team to make autonomous decisions about work scope while staying aligned with the desired outcome of the Sprint.
2. Sprint Planning Official Outputs: Sprint Planning produces two defined outputs per the Scrum Guide: the Sprint Goal (the overarching objective for the Sprint) and the Sprint Backlog (the detailed, evolving work plan to achieve the Sprint Goal).
3. Scrum Event Boundaries: Each Scrum event has specific, defined outputs, and artifacts from other events (such as outputs from the Sprint Review) are not valid outputs of Sprint Planning, which eliminates invalid options in this question. References:
The 2020 Scrum Guide, https://scrumguides.org/scrum-guide.html
Professional Scrum Master I (PSM I) Learning Outcomes

Non-functional requirements define critical quality attributes of a product, including performance, security, scalability, and usability, that directly impact long-term product value and usability. Per the Scrum framework, every Sprint must produce a potentially releasable Increment that meets all agreed-upon quality standards. Non-functional requirements are either formalized as part of the shared Definition of Done or added as standalone Product Backlog Items, so the Development Team is required to incorporate these requirements into all work completed to ensure the Increment meets the minimum acceptable quality bar. The suggested answer A aligns with this core Scrum principle, as failing to meet non-functional requirements in any Increment would result in a low-quality, non-usable Increment that cannot be considered potentially releasable. Option Analysis:
A. Correct. Non-functional requirements are core quality standards for the product, so every Increment produced at the end of a Sprint must adhere to these requirements to be considered potentially releasable. This aligns with the Scrum Guide's mandate that all Increments meet the shared Definition of Done, which typically includes non-functional requirements.
B. Incorrect. The Development Team is fully accountable for the quality of the Increments they produce, including adherence to non-functional requirements. Scrum does not recognize a separate "release department" as a formal role, and shifting responsibility for quality to external teams violates Scrum's principle of cross-functional, accountable Development Teams.
C. Incorrect. The Scrum framework does not include special "Integration Sprints" or "Release Sprints". Every Sprint is required to produce a fully integrated, working Increment that meets all quality standards, so there is no designated later Sprint to handle non-functional requirements deferred from earlier work.
D. Incorrect. Development Teams are self-managing and collectively accountable for all work delivered, including non-functional requirements. Scrum does not define a "lead developer" role with exclusive responsibility for non-functional requirements, as this creates silos and undermines collective team accountability for product quality. Key Concepts:
1. Definition of Done: The Definition of Done is a shared set of quality standards that all Increments must meet to be considered complete. Non-functional requirements are almost always included in the Definition of Done to ensure consistent quality across all work the Development Team completes.
2. Potentially Releasable Increment: Every Sprint must produce an Increment that is fully functional, tested, and meets all quality requirements including non-functional requirements, so the Product Owner can choose to release it to users at any time without additional post-Sprint work.
3. Development Team Accountability: The Development Team is a cross-functional, self-managing group that holds collective accountability for all aspects of the Increment they deliver, including both functional features and non-functional quality attributes. References:
The Scrum Guide 2020, https://scrumguides.org/scrum-guide.html
Scrum.org Professional Scrum Master I Learning Resources

This question assesses core understanding of Scrum event rules, a foundational knowledge domain required for PSM I certification. Per Scrum framework guidelines, Sprints are fixed-length time-boxed events of one month or less, designed to create consistent delivery cadence, predictable planning cycles, and protection against unplanned scope creep. The standard conclusion of a Sprint is not tied to work completion, but rather to the expiration of the pre-determined time box agreed upon during Sprint Planning. Early Sprint cancellation is an extraordinary, rare action reserved for cases where the Sprint Goal becomes obsolete, and is not considered the normal end state of a Sprint. Option Analysis:
A. Incorrect. The Product Owner only holds authority to cancel a Sprint prematurely if the Sprint Goal is no longer relevant or valuable, which is an uncommon, event-driven action. The Product Owner does not determine the standard end date of a Sprint, which is fixed by the time box set during Sprint Planning for all regular Sprint executions.
B. Incorrect. Completion of all selected Sprint Backlog items that meet the team's Definition of Done is the optimal outcome of a Sprint, but it is not a trigger for the Sprint to end. If all planned work is completed early, Developers may collaborate with the Product Owner to pull in additional Product Backlog items aligned with the Sprint Goal, conduct Product Backlog refinement, or work on process improvement activities for the remainder of the time box.
C. Incorrect. Tasks are the granular work breakdown items that Developers create for Sprint Backlog items during Sprint Planning and throughout the Sprint. Completing all planned tasks does not end the Sprint, as the team is required to use the full allocated time box to deliver value, which may include additional work or improvement activities if initial tasks are completed ahead of schedule.
D. Correct. The Scrum Guide explicitly states that Sprints are fixed-length time-boxed events, and the Sprint ends exactly when the pre-agreed time box expires, regardless of how much planned work has been completed. This non-negotiable rule preserves team cadence, planning predictability, and prevents unapproved extensions to accommodate unfinished work. Key Concepts:
1. Time-boxing: A core Scrum principle that mandates all Scrum events have a fixed maximum duration to eliminate waste, ensure consistent cadence, and prevent unplanned work extensions. Sprints, as the container event for all other Scrum activities, have a fixed duration of one month or less that does not change during normal execution.
2. Sprint Conclusion Rules: The standard end of a Sprint is only triggered by the expiration of its pre-determined time box. Early cancellation is an extraordinary action only permitted by the Product Owner if the Sprint Goal becomes obsolete, and is not considered a regular Sprint conclusion.
3. Sprint Outcome vs. Duration: The completion of planned Sprint work is the desired outcome of a Sprint, but it does not modify the Sprint's fixed duration. Teams are expected to use the full Sprint time box to deliver value, which may include pulling in additional aligned work, refining backlog items, or improving internal processes if planned work is completed early. References:
Scrum Guide 2020, https://scrumguides.org/scrum-guide.html
Scrum.org Professional Scrum Master I Assessment Resources